專案進行的過程，需求可能會不斷的發散，這時候專案經理應該要做的是將專案導向既定的方向，評估需求對專案的影響層面以及是否應該納入專案的範圍。
專案需求的發散，表示使用者有認真在看待專案，並期待專案可以解決他面臨的諸多問題。但是對於掌控的人來說，這其實是夢靨！需求的發散，代表著您無法掌握專案的結果，另一個層面就是您需要額外付出當初所未考慮進來的成本，而專案的時程也會因此而受到影響，您得重新檢視專案的時程，可能得重新規劃，這是我們所不樂見的。

所以除了讓專案要能照計畫、進度進行之外，專案執行過程的成本，也必須要清楚的掌握。

一件事情本來就有多方面的考量，使用者的意見，絕對是我們要尊重且認真看待的。但是為了不影響系統既定的方向，溝通協調是必定要進行的，也就是瞭解使用者的需求是否會影響到系統的上線，如果這個需求/功能在上線時沒有 Ready，那麼可能會影響到業務流程的正常運作，那麼確實得考慮進來，但是在同一個 pool 底下，新增進來的需求一定會有排擠效應，您原來訂定的優先順序，可能就會因此必須做局部的調整，將優先順序再重新順過一遍，也讓使用者瞭解這樣可能造成的影響，也許使用者會摒棄成見想出另外的解決方式。

所以我們需要有一份專案需求變更排定優先順序的管控表，來協助我們進行需求的管理。

同時，ERP不單只是獨立的運作而已，外部系統的連結深度，也關係著您整體開發成本的花費，所以也必須將外部系統需要變更的項目一一列出，排定時程處理，這部份的隱藏成本，也許沒有立即的成本支出，但他還是會耗掉您團隊的資源。

將上線前必須 Ready 的功能列為 Must Have，並將時程定為上機模擬前必須完成的項目，其他不影響上線的功能，就列在上線之後再排定時間進行。

掌握了哪些功能必須在上線之前完成，我們就必須衡量，哪些事該由廠商進行客製，哪些要自行處理或採取替代措施。這部份在顧問進行完差異分析之後，就必須討論出一個輪廓，並逐一與使用者開會討論達成共識；如果預算超出當初所估計的客製費用（由顧問客製團隊評估客製功能開發所需時數，以工時換算得來），那麼就必須要呈報委員會進行預算追加，並且說明緣由，千萬不要自行決定，這可是會壞事的。

全系列文章列表